前言

昨天介紹了 AWS 的 IAM Identity Center 與 Cognito，分別處理員工與顧客身分。今天接著看：帳號如何自動建立，又如何在異動或離職時更新與停用？ 這就會用到首次登入時依規則建立帳號的 JIT Provisioning，以及跨系統管理使用者與群組的 SCIM。

今天會先介紹 JIT 如何搭配登入流程，再說明 SCIM 如何管理後續帳號異動，最後整理兩者在帳號生命週期中的分工。

今天內容涵蓋：

1. JIT Provisioning 要解決的問題
2. JIT 如何搭配 SSO
3. 為什麼還需要 SCIM
4. SCIM 如何同步使用者與群組

一、JIT Provisioning 要解決的問題

有公司帳號，不代表每個應用程式裡都已經有你的帳號。

例如，新員工已有 Microsoft Entra ID 的公司帳號，但第一次使用公司的專案系統時，專案系統裡還沒有這個人的資料。原本需要管理員先手動建帳；如果專案系統支援並啟用 JIT，就能在第一次登入時自動處理：

1. 員工使用 Microsoft Entra ID 的公司帳號進行登入。
2. 專案系統確認登入結果有效，而且這位員工符合開通資格。
3. 發現還沒有對應帳號，就自動建立，再讓員工進入系統。

這就是 JIT Provisioning（即時帳號佈建）：不用事先替每個人建帳，而是等使用者第一次登入時，再依規則建立。

JIT 處理的是「自動開通帳號」。至於能查看哪些專案、能不能修改資料，仍由專案系統的權限設定決定。

二、JIT 如何搭配 SSO

Day 05 提到，SSO 讓使用者在身分平台登入後，存取其他信任該平台的應用系統時，不必每次重新輸入帳密。應用系統會驗證平台回傳的登入結果，確認使用者是誰。

但確認身分，不代表帳號已經開通。使用者可能還沒有應用系統所需的帳號，或尚未加入對應組織。這時就可以透過 JIT，在身分驗證成功、確認符合開通資格後，自動建立帳號或加入組織，不必再由管理員手動處理。

SSO 減少重複登入，JIT 減少手動開通。兩者可以接在同一次登入流程中，但負責不同的事情。

下面分成兩種情境：第一種由身分平台直接驗證使用者，再透過 JIT 加入組織；第二種由外部 IdP 驗證身分，身分平台接收結果後，再完成 JIT 開通。

情境一：透過身分平台登入

使用者已有身分平台的帳號，但還沒加入應用系統對應的組織。啟用 JIT 後，就能在登入時依規則自動加入，不必逐一邀請。

流程如下：

1. 使用者開啟應用系統，點擊登入按鈕。
2. 應用系統將使用者導向事先設定好的身分平台。
3. 身分平台顯示登入畫面，讓使用者使用既有帳號登入。
4. 使用者提交帳密，由身分平台驗證身分，並視設定完成 MFA 等驗證。
5. 驗證通過後，身分平台確認使用者符合加入條件，透過 JIT 自動將使用者加入對應組織，不必由管理員另外邀請。
6. 身分平台將登入結果回傳給應用系統，應用系統驗證結果是否有效，確認使用者身分。
7. 應用系統向身分平台查詢這位使用者所屬的組織。
8. 身分平台回傳組織資訊，應用系統再依組織與角色，顯示對應工作區並提供允許使用的功能。

圖中是由應用系統另外查詢組織資訊；如果登入結果已包含這些資料，就可以省略這次查詢。

這裡的 JIT 重點是讓使用者在登入時，依規則自動加入對應團隊；後續能使用哪些功能，仍由應用系統依組織與角色決定。

情境二：串接外部 IdP 登入

這個情境中，使用者已有 Microsoft Entra ID 的公司帳號，應用系統則透過身分平台串接 Entra ID。使用者由 Entra ID 驗證身分，再由身分平台依 JIT 規則建立帳號或加入組織。

開始前，管理員須先設定好身分平台與 Entra ID 的 SSO 連線，以及哪些使用者可以加入哪個組織。

流程如下：

1. 使用者開啟應用系統，點擊登入按鈕。
2. 應用系統將使用者導向身分平台。
3. 身分平台顯示登入入口，讓使用者輸入公司 Email。
4. 使用者提交 Email，平台依事先設定的規則找到對應的 SSO 連線。
5. 身分平台將使用者導向 Microsoft Entra ID，由 Entra ID 驗證公司帳號，並視政策要求完成 MFA。
6. 驗證成功後，Entra ID 將驗證結果回傳給身分平台。
7. 身分平台檢查結果是否有效，並確認使用者符合目標組織的開通條件。
8. 符合條件後，平台透過 JIT 建立尚未存在的平台帳號，並依規則加入對應組織；已有帳號或成員關係時，不會重複建立。
9. 身分平台將登入結果回傳給應用系統。
10. 應用系統驗證平台回傳的結果，確認使用者身分。
11. 應用系統向身分平台查詢使用者所屬的組織。
12. 身分平台回傳組織資訊。
13. 應用系統依組織與角色，顯示對應工作區並提供允許使用的功能。

JIT 只會在身分平台或應用系統中補上尚未存在的帳號或成員關係；它不會重新建立原本的 Entra ID 公司帳號。若登入結果已包含所需的組織資訊，也可以省略額外查詢。

⚠️輸入公司 Email，只是讓系統知道要帶你去哪裡登入。你仍須在 Microsoft Entra ID 完成驗證，再由身分平台確認你是否符合加入條件，才會自動加入組織。至於加入後能做哪些事，則依應用系統的權限設定決定。

三、為什麼還需要 SCIM

前面介紹的 JIT，可以在使用者第一次登入時自動開通帳號。但如果這個人離職了，其他系統裡的帳號要怎麼停用？我們不能等他再次登入，才處理停用。

例如，公司用 Microsoft Entra ID 管理員工帳號，員工也會使用專案管理、請假等系統。管理員在 Entra ID 停用公司帳號後，其他系統裡的帳號不一定會跟著停用。若沒有另外設定同步，管理員就得逐一到這些系統處理。

SCIM（System for Cross-domain Identity Management） 就是讓不同系統用標準方式傳送「建立、修改、停用帳號」等要求。當 Entra ID 與應用系統設定好 SCIM 同步後，離職處理可以這樣進行：

1. 管理員在 Entra ID 停用離職員工的公司帳號。
2. Entra ID 的佈建服務，也就是負責同步帳號的服務，透過 SCIM 通知已設定同步的應用系統。
3. 應用系統收到要求後，停用這位員工在自己系統裡的對應帳號。

這樣就不必由管理員逐一到各系統手動停用，也不必等員工再次登入，就能處理帳號停用。除了離職，SCIM 也能用來建立新員工的帳號，或更新使用者資料與群組成員。

簡單說，JIT 解決登入當下的開通問題；SCIM 則負責登入之外的帳號同步與停用。

接下來看 SCIM 如何透過 API，把這些帳號變更送到其他系統。

四、SCIM 如何同步使用者與群組

要理解 SCIM，可以先從標準本身切入：RFC 7643 說明「帳號資料長什麼樣子」，RFC 7644 說明「系統之間如何透過 API 傳送新增、更新、停用等操作」。

SCIM 不是拿來登入的，而是讓來源系統用固定格式，把帳號資料變更送到目標系統。

SCIM 同步哪些資料

SCIM 最常同步的是兩種資料：User 與 Group。

• User： 一個使用者帳號，例如姓名、Email、帳號是否啟用。
• Group： 一個群組，以及群組裡有哪些成員，例如「工程部」包含哪些使用者。
• EnterpriseUser： 企業常用的補充欄位，例如部門、員工編號、主管等。它是 User 的延伸資料，不是另一個獨立帳號。

圖中的 Resource 可以理解成 SCIM 裡共同的資料概念。User 和 Group 都是 Resource 的一種；Others 則表示有些系統可能會擴充其他資料類型。實際能同步哪些欄位，仍要看目標系統支援到什麼程度。

SCIM 怎麼把變更送到其他系統

SCIM 同步的正式角色有兩個：

• SCIM Client： 發出同步要求的一方，通常是 來源系統 的佈建服務。例如 Microsoft Entra ID 會把使用者或群組異動送出去。
• SCIM Service Provider： 接收同步要求的一方，通常是 目標系統 提供的 SCIM API。例如專案系統、SaaS 服務或 AWS IAM Identity Center 會接收要求，並更新自己的帳號資料。

流程通常如下：

1. 管理員先在 SCIM Client 設定 SCIM Service Provider 的 API 位址、管理憑證，以及要同步的使用者與群組。
2. 當使用者或群組資料異動時，SCIM Client 會準備同步要求。
3. SCIM Client 透過 HTTPS 呼叫 SCIM Service Provider 的 SCIM API，要求新增、更新或停用帳號。
4. SCIM Service Provider 確認請求有權限後，在自己的系統裡套用變更。
5. SCIM Service Provider 回傳結果，讓 SCIM Client 記錄同步成功或失敗；若失敗，通常會重試或通知管理員。

以離職停用帳號為例，不用等員工再次登入，SCIM Client 就可以主動通知 SCIM Service Provider 停用帳號。

如果用 Gloria 離職當例子，SCIM Client 可能會送出類似下面的 PATCH 要求。這裡的 user-123 是 Gloria 在 SCIM Service Provider 裡的使用者識別碼：

PATCH /Users/user-123 HTTP/1.1
Host: app.example.com
Authorization: Bearer <scim-access-token>
Content-Type: application/scim+json

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "path": "active",
      "value": false
    }
  ]
}

這份要求的意思是：SCIM Client 要求 SCIM Service Provider 將 Gloria 的 active 設為 false，也就是停用 Gloria 在目標系統裡的帳號。

要注意的是，SCIM 同步可能有排程延遲，也可能因為憑證、欄位對應或 API 錯誤而失敗。因此離職處理不能只看來源端已停用，還要確認 SCIM Service Provider 是否真的套用變更。

另外，停用帳號不一定代表所有既有 Session 或 Token 會立刻失效。如果 Gloria 在停用前已經登入過某些系統，仍需要依系統設計檢查既有工作階段與存取權是否已被收回。

小結

今天從 JIT 與 SCIM 看帳號生命週期中兩個不同階段的問題。

JIT 發生在登入流程中，負責在使用者通過身分驗證、且符合開通條件後，自動建立帳號或組織成員關係。SCIM 則不依賴使用者登入，而是透過標準化資料格式與 API，讓 SCIM Client 主動通知 SCIM Service Provider 新增、更新或停用使用者與群組。

SSO 負責登入，JIT 負責首次開通，SCIM 負責後續同步；至於登入後能做什麼，仍由應用系統的授權規則決定。 這幾件事可以互相配合，但不能混成同一件事。

下一篇會回到 OAuth／OIDC 的安全議題，討論 Authorization Code Flow 中的授權碼如果被攔截，攻擊者可能如何利用，以及 state、nonce 與 PKCE 分別能防範哪些風險。

參考資源

• 即時（JIT）供應是什麼？－Auth Wiki by Logto
• Understand Just-in-Time provisioning－Logto Blog
• 什麼是 SCIM？－Microsoft 安全性
• SCIM：System for Cross-domain Identity Management－scim.cloud
• RFC 7643－System for Cross-domain Identity Management: Core Schema
• RFC 7644－System for Cross-domain Identity Management: Protocol
• Provision users and groups from an external identity provider using SCIM－AWS IAM Identity Center
• Migrate from Azure AD B2C to Microsoft Entra External ID－Microsoft Learn
• Just-in-time password migration to Microsoft Entra External ID－Microsoft Learn